Do we really need a specific view mode for chats? The idea is that view modes are supposed to be pretty generic like view sources, in app help, attachments.

A good view mode candidate would be to view the text representation of notes, to see what the LLM "sees".

If we want to go with the note map approach, then we need a note specific for the LLM chat in the hidden subtree with a normal view.

This feels kind of like a hack or a work-around, doesn't it? What problem does it solve?

Same here, why are we running the code behind a delay?

Where's the existing code?

🏃💨

Maybe we should extract all these strings to translatable strings, or at least gather them as constants in a single place.

We need to be able to support multiple languages in the future, especially now that we added internationalization support to Trilium.

Might want to add a TODO to integrate Highlight.js to do this sort of thing on its own, without having to hard-code it on our side.

Again, here it would be nice to define how these values were obtained and how we can maintain them, e.g. if we add a new AI provider.

Commented-out code must be removed.

Why this change?

I would propose to get rid of axios and just stick to the built-in fetch – from what I saw, we only have that depdency for the backend_script_api, where "axios" is marked as deprecated.

    /**
     * Axios library for HTTP requests. See {@link https://axios-http.com} for documentation
     * @deprecated use native (browser compatible) fetch() instead
     */
    axios: typeof axios;

I have no idea about LLMs and all, but are "embeddings" something LLM specific?
if yes, wouldn't it make sense to have the API path reflect this as well?

e.g. by changing /api/embeddings/ → /api/llm/embeddings/

An embedding is something like a baked croissant. Different bakers can make them with varying quality, but if you give the croissant to your friend at work, they may (or may not) think this croissant is better than one by another bakery.

Long-winded way of saying that even though LLMs generate them, but we use them locally to do cosine similarity computation to see what notes to include at query time and don’t directly provide the embedding to the LLM we’re talking to.

I’m not sure if you’re asking to move the endpoint to /api/<llm>/embeddings or /api/llm/embeddings - but yeah I think the latter makes more sense

aren't these missing the CSRF/Auth middleware – or am I missing something

same here:
Generally speaking:
I think it would make it cleaner to have these under /api/llm/ if they are LLM specific.

also apart from the above – I wonder here:
wouldn't it make sense to have the route be list-models/${LLM} instead?
at least from a REST point of view, I feel this would "group" these more logically.

does it make sense to have the "default fallback string" translatable?

should these be translatable?

just a general question: what is the purpose of this code_handlers exactly ­– I can see some attempt to extract structure from code notes – aren't all those LLM models "smart enough" to do that themselves?

Again – not a LLM expert, so excuse me if that is a stupid question :-)

Unfortunately not - all that LLMs “see” is text, so we have to build as much of a text representation of the Note (regardless of type) as we can.

Perhaps for the code note type specifically, yes, we can provide the vast majority of the Note content directly to the LLM we’re talking- we’d just have to clean up any tags to minimize its impact on the size of the context

We’re performing those actions on code notes to try to extract what’s useful to minimize impact on the size of the context.

should be translatable, please :-)